Modem industrial controllers generally comprise an “engineering system” and a “runtime system”. The engineering system is used to develop a control program which is then subsequently loaded into the runtime system. The runtime system then ensures the time sequence control for the system to be controlled.
The functionality of the system to be controlled and/or of the runtime system can be expressed by an object model. The object model is effective in the engineering system and/or runtime system and is the basis for the engineering of the controller, for example, startup and programming etc. Furthermore, the object model is the basis for the data storage of the controller. The elements of the object model can be categorized into various object types. The object type is the software engineering form of a description of object instances. In the simplest form, this description relates to the data structure represented by an object instance in the memory. In systems today, the object type also describes operations which can be carried out on these data structures and thus also lends functionality to the object instances. An example of one of these object types is program containers used for managing and storing user programs. Other object types are technological object types, such as for positioning axes, synchronism axes, measuring gages, cam disks etc., the functionality of these object types being stored in the respective object type on a data engineering basis. Another significant object type is “devices” used for managing and storing hardware configuration settings.
All object types can be instantiated, i.e. can be embodied specifically. Thus, for example, a synchronism object can be allocated a specific transmission ratio. The technological object types can be organized in the form of technological packets. Instantiation is generally effected in the engineering system. Loading the instantiated objects into the runtime system initiates the instantiation of corresponding objects in the runtime system, to which objects the data of the objects from the engineering system are transmitted.
An object instance is first a data structure in the memory of a computer system. From one object type, it is possible to instantiate any desired number (to the extent permitted by the underlying computer system) of object instances. In this context, the size and organization of the data structure of each object instance follows the description provided by the object type. Object instances are set up at the execution time of an editor, that is to say while the program system is being executed on a computer system in the engineering system.
The object model comprises a set of object types and describes the relationships between object instances instantiated from the object types. The complexity of creating new object types to be inserted into a complex object model can be comparatively great.
In the engineering system, various tools can be used to access objects (instances) of particular object types. That is to say that the object types are defined when the software system is created and cannot be changed again in the engineering system. Accordingly, the engineering system permits one or more views to the instances of particular object types. Within the context of programming, these may be, by way of example, various editors for textual or graphical user programming. The tools and views of the engineering system are also called SnapIns. Besides the SnapIns present in the basic system, other SnapIns can be added to the engineering system.
An object type is more than just the description of a data structure. It also comprises operations which can be carried out on and using instances of this data structure. The internal tools of the basic engineering system access instances of the object types. Object types themselves are generally not changed again by the user.
In principle, engineering systems, like any other software, are also subject to constant renewal, extension and improvement. However, with today's implementation mechanisms for control extensions, the problems discussed below often arise. The introduction of a new programming view, e.g. the introduction of graphical programming in addition to textual programming, is today not possible in integrated fashion without extending the basic functionality of the engineering system. A possible external extension using external tools requires dedicated data storage, which is then not integrated into the existing system. The extension of an existing, for example graphical, programming language by additional programming icons, which requires extension of the data storage, is generally not possible without touching or extending the existing engineering system. Thus, for example, an existing flowchart editor cannot readily be extended by icons for particular library functions. In addition, today's OEM interfaces afford only a specific and restricted depth of integration into the engineering system. Finally, extensions of the engineering system functionality using external tools generally entail consistency problems in the data storage.